1. Field of the Invention
The present invention relates generally to rendering graphics in a computer environment. More specifically, the present invention is directed to using multiple frame buffers with a graphics compositor.
2. Description of the Related Art
Window systems that support overlapping windows and window placement must maintain information on what portions of each window are to appear in the display frame buffer. When a window's geometry—that is, position, size, or window order (front to back order in which windows appear to be layered—is changed, the window system must determine the changes to be made in the visible area of each window, perform the operations necessary to update the window's visible area, and refresh the display frame buffer's content to reflect the changes in window visible area.
FIG. 1 illustrates a conventional method for rendering content to a digital display or analog monitor. A CPU 102 draws an object either directly to frame buffer memory 106 (referred to as a frame buffer), or by a graphics processing unit 104 where one is available. A video controller 108 reads the object from frame buffer 106, and then outputs the object directly to a digital display 110, or to a digital-to-analog converter 112 that converts the output signal for display on an analog monitor 114.
FIG. 2 illustrates a frame buffer 106 such as the one described above with respect to FIG. 1. In FIG. 2, frame buffer 106 includes two windows 204, 206. For example, window 204 might be a text editing window, while window 206 could be a pop-up window. In the illustrated case, a portion of window 204 is hidden from view (i.e. covered) by window 206. The portion of window 204 that is not covered is referred to in the art as the window's “visible region.” In conventional operating systems such as Apple Computer, Inc.'s OS 9, Microsoft Corporation's Windows Me, etc., where applications write their windows directly to the frame buffer 106, the applications themselves are responsible for checking the visible region of each of their windows in order to insure that covered portions of the windows are not painted to the frame buffer. One drawback to this method, referred to hereafter as the classic method, is that application developers have to include extensive lines of code devoted to checking the visible region for each window. Another drawback—a corollary to the first—is that applications have the ability to paint over the windows of other applications when they are not supposed to.
A second conventional way of rendering windows is to use a compositor. Referring to FIG. 3, a copy of each window 304, 306 is maintained in a back buffer 308, 310. Applications draw their windows in the back buffers, and are then not responsible for redrawing their windows unless the window contents change. The compositor 312 maintains data about the visible region of each window, and correctly repaints each window in frame buffer 302 as its visible area changes. This relieves the application developer of the need to track visible area.
FIG. 4 illustrates a conventional method for using a compositor such as that described with respect to FIG. 3. An application running on CPU 402 draws windows to window buffers 406, 408. Alternatively, the applications may pass the data to GPU 404, which in turn draws them to window buffers 406, 408. Compositor 410 retrieves the windows from window buffers 406, 408 and draws them in frame buffer 412. As the visible area of a window changes, for example as window 306 is moved to the left and obscures more of window 304, the compositor simply retrieves again window 304 from window buffer 308, and repaints it to the frame buffer with the correct visible area. The application that created the window is not involved in the process. Consequently, the operation proceeds much faster, and typically looks better to the user.
In order to allow applications that rely on direct writing to a frame buffer to coexist with applications running in an operating system having a compositor, some conventional operating systems have implemented hybrid graphics subsystems that can accommodate both types of applications. Referring now to FIG. 5, there is shown an example of a frame buffer 502 that includes a classic window 504 and a compositor window 506. Classic window 504 is a window drawn by an application with direct access to the frame buffer, as described above with reference to FIG. 2 and FIG. 1. Compositor window 506 is a window drawn in the frame buffer by a compositor and created as described above with reference to FIG. 3 and FIG. 4.
FIG. 6 illustrates a conventional method for combining a compositor environment with classic environment. Applications 602 that are implemented to use the compositor (“compositor applications”) write their windows to a back buffer 608. Compositor 606 in turn reads data from the back buffers 608 and in combination with its own record of visible area for each window appropriately renders the windows to frame buffer 616.
As described earlier, classic applications 604 are conventionally expected to check their visible window area, and to paint only that visible area to frame buffer 616. One way which this is typically done is through a call to the operating system such as “VisRegion”, which returns the correct visible region for the calling application and specified window. In the conventional hybrid system of FIG. 6, classic applications 604 request their VisRegion, and the call is handled by the compositor 606. Since the compositor is aware of the locations of both other classic application windows 614 and compositor-friendly application windows 610, 612, the compositor returns accurate information to classic applications 604 about their visible area. Classic applications 604 then correctly paint their windows to frame buffer 616.
Although this hybrid method allows classic and compositor windows to coexist within the same operating system, there is a serious downside. While classic applications 604 are conceptually supposed to request their visible area “nicely” (for example, via a VisRegion call), application developers over the years have come to recognize shortcuts that can be taken to make their code more efficient. One common shortcut is to call “GetFrontWindow”, which in one classic environment returns the ID of the window in front of all other windows. If the ID returned by GetFrontWindow is the same as the ID of the window classic application 604 wants to paint, then the entire window is painted without any need to check its visible area—since it is in front, it will not be obscured by any other windows. As those of skill in the art will appreciate, this can be cause for disaster in an implementation like the one of FIG. 6. Here, classic window 614 is the only classic window on the screen, although it is obscured by windows 610 and 612, both of which are painted by the compositor 606. Accordingly, if classic application 604 calls GetFrontWindow, it will receive back its own window ID, since it is the front-most window of all of the classic windows. If it then paints window 614 in its entirety to frame buffer 616, it will paint right over windows 610 and 612, which is not the correct result.
Accordingly, there is still a need in the art for a way of allowing classic applications and a compositor to coexist in a single operating system without one disrupting the operation of the other.